About the pull request

Refactoring ndatabase to be a bit more readable and redefining the interface for defining entities, entity links, and views to reduce boiler plate. Using field and field type datums to validate that appropriate fields and field types are passed.

Also adding unit tests to validate views and links at the very list.

Will try to document what is going on with ndatabase since variable name changes might not be sufficient in that front.

Feedback from those more familiar with how this works is much appreciated.

TODO

Implementation

• Update DB adapters to handle datumized fields and field types
• Update existing DB entities to use new interfaces
• Make foreign key for entity links connect to a field on entity
• Make sure native functions are correctly handled
• Extract entity management from entity meta into entity manager itself or entity managing class (separation of concerns)
• Update internal_parse_column and internal_generate_view_query so that meta_to_load maps entity nodes to table names

Documentation

• Add documentation for database interfaces (adapter, connection, etc)
• Add documentation for database entities (including table definition)
• Add documentation for views
• Add documentation for indexes
• Add documentation for database implementations
• Rename abbreviated/shortened variables to be fully descriptive
• Update the meta_to_load and meta_to_table variable names to more clearly reflect what they represent in adapters
• Add documentation for internal_parse_column and internal_generate_view_query since aliasing is not very clear without digging into the code

Validation

• Add unit tests to validate links are properly configured
• Add unit tests to validate links are not duplicated
• Add unit tests to validate view fields (especially those that are through entity links)

Misc

• Understand DB indexing update

Nice to have's (will probably do these changes in separate PRs to avoid scope creep)

• Interface for migrating data between tables
• Non-entity based views
• Interface for junction tables (many-to-many mappings)

Explain why it's good for the game

With datumized preferences port I am planning to do would like to try storing all preferences in the database instead of through savefiles. Wanted the DB to be a lot easier to work with before diving into that.

Testing Photographs and Procedure

Changelog

no player facing changes